Mobility management is an important attribute of mobile communication systems, and handover is the key of mobility management, a rational handover can reduce the possibility of the sudden loss of the connection of User Equipment (UE) and the interruption of service data and improves system stability and user experience.
In a Long Term Evolution (LTE) system, UE is in an RRC_CONNECTED status or an RRC_IDLE status. When the UE in the RRC_CONNECTED status enters another cell from a service cell, a cross-cell handover is trigged to guarantee a service not to be interrupted.
A cross-eNodeB handover is trigged when the UE is handed over from a cell of an Evolved Node B (eNB) to a cell of another eNB. If there is an X2 interface which is located between a handover source eNodeB and a handover target eNodeB, and the handover source eNodeB and the handover target eNodeB are connected with the same Mobility Management Entity (MME), a source eNB will initiate an X2 interface handover, otherwise, the source eNB will initiate an S1 interface handover, according to existing technologies (3GPP protocol, 23.401).
In an LTE system, the data transmission modes of a Radio Link Control (RLC) layer include an Acknowledged Mode (AM), an Unacknowledged Mode (UM) and a Transparent Mode (TM). In the AM, as data needs to be delivered in sequence, each packet is ordered by sequence number, that is, by Packet Data Convergence Protocol Sequence Number (PDCP SN). As there is no need to reset PDCP SNs during a handover, that is, the PDCP SNs need to be successive before and after a handover, a Sequence Number (SN) Status Transfer message is defined in 3GPP protocols to send to a target eNB the PDCP SNs of each E-UTRAN Radio Access Bearer (E-RAB) (service) in an AM for the data transmission between a source eNB and UE so that the user plane of the target eNB can transmit data with the PDCP SNs received to guarantee the continuity of uplink and downlink data.
If the handed-over UE has AM services, in order to guarantee AM data to be received and sent in sequence after a handover, a Sequence Number Status Transfer message must be received by the target eNB prior to the completion of the handover.
According to the description of a protocol (3GPP protocol, 36, 300), an X2 handover flow, as shown in FIG. 1, can be briefly described as follows:
1. a source eNB sends a Handover Request message to a target eNB;
2. the target eNB prepares resources and sends a Handover Request Acknowledge message to the source eNB;
3. the source eNB sends an RRC Connection Reconfiguration message to the UE;
4. the source eNB sends a Sequence Number Status Transfer message to the target eNB;
5. the UE sends an RRC Connection Reconfiguration Complete message to the target eNB;
6. the target eNB sends a Path Switch Request message to a core network;
7. the core network sends a Path Switch Acknowledge message to the target eNB;
8. the target eNB sends the UE Context Release message to the source eNB.
In the above-mentioned flow, for the target eNB, the Sequence Number Status Transfer message is received prior to the RRC Connection Reconfiguration Complete message. However, if the processing of the source eNB or the link of an X2 interface is faulted, the target eNB may receive the RRC Connection Reconfiguration Complete message from the UE prior to the Sequence Number Status Transfer message or the Sequence Number Status Transfer message is lost. Further, according to the description of the protocol (3GPP protocol, 36, 300), if there is no AM service, the source eNB may send no Sequence Number Status Transfer message, that is, the target eNB may receive no Sequence Number Status Transfer message. Thus, the target eNB needs a Sequence Number Status Transfer message when the UE having AM services is handed over, and needs no Sequence Number Status Transfer message when the UE having no AM service is handed over. However, in existing handover flow, the target eNB delays the transmission of a Path Switch Request message if the target eNB receives an RRC Connection Reconfiguration Complete message prior to a Sequence Number Status Transfer message, which increases handover delay and complicates the processing of the handover flow as two timers are started to synchronously wait for the Sequence Number Status Transfer message and the RRC Connection Reconfiguration Complete message. Aiming at the problems above, no effective solution has been proposed.